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Abstract 


This document specifies an extension to the identifiers to be used in 
the Transport Profile of Multiprotocol Label Switching (MPLS-TP). 
Identifiers that follow IP/MPLS conventions have already been 
defined. This memo augments that set of identifiers for MPLS-TP 
management and Operations, Administration, and Maintenance (OAM) 
functions to include identifier information in a format typically 
used by the International Telecommunication Union Telecommunication 
Standardization Sector (ITU-T). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6923. 
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Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


This document augments the initial set of identifiers to be used in 
the Transport Profile of Multiprotocol Label Switching (MPLS-TP) 
defined in [RFC6370] by adding new identifiers based on ITU-T 
conventions. It is not intended that both types of identifiers will 
be used at the same time in the same domain. 
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[RFC6370] defines a set of MPLS-TP transport and management entity 
identifiers to support bidirectional (co-routed and associated) 
point-to-point MPLS-TP Label Switched Paths (LSPs), including 
Pseudowires (PWs) and Sections that follow the IP/MPLS conventions. 
This document specifies an alternative way to generate unambiguous 
identifiers for operators/service providers based on ITU-T 
conventions and specifies how these operator/service provider 
identifiers can be used to generate unambiguous identifiers for the 
existing set of identifiable MPLS-TP entities described in [RFC6370]. 
This document solely defines those identifiers. Their use and 
possible protocol extensions to carry them are out of the scope of 
this document. 
In this document, we follow the notational convention laid out in 
[RFC6370], which is included in this document for convenience in 
Section 1.3. 

1.1. Terminology 
CC: Country Code 
ICC: ITU Carrier Code 
ISO: International Organization for Standardization 
ITU: International Telecommunication Union 
ITU-T: ITU Telecommunication Standardization Sector 
LSP: Label Switched Path 
MEG: Maintenance Entity Group 
MEP: Maintenance Entity Group End Point 
MIP: Maintenance Entity Group Intermediate Point 
MPLS: Multiprotocol Label Switching 
PW: Pseudowire 


TSB: (ITU-T) Telecommunication Standardization Bureau 


UMC: Unique MEG ID Code 
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1.2. Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.3. Notational Conventions 
This document uses the notational conventions laid out in [RFC6370]: 


All multiple-word atomic identifiers use underscores (_) between 
the words to join the words. Many of the identifiers are composed 
of a set of other identifiers. These are expressed by listing the 
latter identifiers joined with double-colon "::" notation. 


Where the same identifier type is used multiple times ina 
concatenation, they are qualified by a prefix joined to the 
identifier by a dash (-). For example, Al-Node_ID is the Node_ID 
of a node referred to as Al. 


The notation defines a preferred ordering of the fields. 
Specifically, the designation Al is used to indicate the lower 
sort order of a field or set of fields and Z9 is used to indicate 
the higher sort order of the same. The sort is either 
alphanumeric or numeric depending on the field’s definition. 
Where the sort applies to a group of fields, those fields are 
grouped with {...}. 


Note, however, that the uniqueness of an identifier does not 
depend on the ordering, but rather, upon the uniqueness and 
scoping of the fields that compose the identifier. Further, the 
preferred ordering is not intended to constrain protocol designs 
by dictating a particular field sequence ... or even what fields 
appear in which objects. 


2. Named Entities 


This document provides additional identifiers supplementing those 
defined in [RFC6370]. The identifiers in [RFC6370] are composed of a 
set of atomic identifiers, and this document defines some new atomic 
identifiers that can be substituted for some of those that have 
already been defined, to create new identifiers. The set of 
identifiers defined in [RFC6370] is: 


o Global_ID 


o Node 
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o Interface 


o Tunnel 


o LSP 
o PW 

o MEG 
o MEP 
o MIP 


The following sections go through this list of identifiers one by 
one. The structure of this document is loosely aligned with the 
structure of [RFC6370]. 


3. Uniquely Identifying an Operator -- the ICC_Operator_ID 


In [RFC6370], an operator is uniquely identified by the Global_ID, 
which is based on the Autonomous System (AS) number of the operator. 
The ITU-T, however, traditionally identifies operators and service 
providers based on the ITU Carrier Code (ICC) as specified in 
[M1400]. 


The ITU-T Telecommunication Standardization Bureau (TSB) maintains a 
list of assigned ICCs [ICC-list]. Note that ICCs, all of which are 
referenced at [ICC-list], can be assigned to ITU-T members as well as 
non-members. The national regulatory authorities act as an 
intermediary between the ITU/TSB and operators/service providers. 

One of the things that the national authorities are responsible for 
in the process of assigning an ICC is to ensure that the Carrier 
Codes are unique within their country. This uniqueness assumption is 
the basis for creating a globally unique ICC-based operator ID. 


The ICC itself is a string of one to six characters, each character 
being either alphabetic (i.e., A-Z) or numeric (i.e., 0-9). 
Alphabetic characters in the ICC SHOULD be represented with uppercase 
letters. 


Global uniqueness is assured by concatenating the ICC with a Country 


Code (CC). The Country Code (alpha-2) is a string of two alphabetic 
characters represented with uppercase letters (i.e., A-Z). 
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The International Organization for Standardization (ISO) establishes 
internationally recognized codes for the representation of names of 
countries, territories or areas of geographical interest, and their 
subdivisions, published as a list of CCs [CC-list] in ISO Standard 
3166-1 [1S03166-1]. 


The ICC and CC characters are coded according to ITU-T Recommendation 
T50- FT50] 


Together, the CC and the ICC form the ICC_Operator_ID as: 
CC::ICC 
3.1. Use of the ICC_Operator_ID 


The ICC_Operator_ID is used as a replacement for the Global_ID as 
specified in [RFC6370], i.e., its purpose is to provide a globally 
unique context for other MPLS-TP identifiers. 


As an example, an Interface Identifier (IF_ID) in [RFC6370] is 
specified as the concatenation of the Node_ID (a unique 32-bit value 
assigned by the operator) and the Interface Number (IF_Num, a 32-bit 
unsigned integer assigned by the operator that is unique within the 
scope of a Node_ID). To make this IF_ID globally unique, the 
Global_ID is prefixed. This memo specifies the ICC_Operator_ID as an 
alternative format that, just like the Global_ID, is prefixed to the 
IF_ID. Using the notation from RFC 6370 [RFC6370]: 


Global_ID: :Node_ID::IF_Num 
is functionally equivalent to: 

ICC_Operator_ID: :Node_ID::IF_Num 
The same substitution procedure applies to all identifiers specified 
in [RFC6370] with the exception of the MEG ID, MEP ID, and MIP ID. 


MEG, MEP, and MIP Identifiers are redefined in this document (see 
Sections 7.1, 7.2, and 7.3, respectively). 
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4. Node and Interface Identifiers 


The format of the Node and Interface Identifiers are not changed by 
this memo except for the case when global uniqueness is required. 


[RFC6370] defines the Node Identifier (Node_ID) as a unique 32-bit 
value assigned by the operator within the scope of a Global_ID. The 
structure of the Node_ID itself is not defined as it is left to the 
operator to choose an appropriate value. The value zero, however, is 
reserved and MUST NOT be used. 


This document does not change the above definition. However, in case 
global uniqueness is required, the Node_ID is prefixed with the 
ICC_Operator_ID as defined in Section 3. 


[RFC6370] further defines interface numbers (IF_Num) as 32-bit 
unsigned integers that can be freely assigned by the operator and 
must be unique in the scope of the respective Node_ID. The IF_Num 
value 0 has a special meaning, and therefore, it MUST NOT be used to 
identify an MPLS-TP interface. 


An Interface Identifier (IF_ID) identifies an interface uniquely 
within the context of an ICC_Operator_ID. It is formed by 
concatenating the Node_ID with the IF_Num to result in a 64-bit 
identifier formed as Node_ID::IF_Num. 


Global uniqueness of the IF_ID, if needed, can be assured by 
prefixing the identifier with the ICC_Operator_ID. 


5. MPLS-TP Tunnel and LSP Identifiers 


This document does not change the definition for local Tunnel and LSP 
IDs. When global uniqueness is needed, the format of these 
identifiers is as described in Sections 5.1 and 5.2. 


5.1. MPLS-TP Point-to-Point Tunnel Identifiers 


Tunnel IDs (Tunnel_ID) are based on the end points’ Node_IDs and 
locally assigned tunnel numbers (Tunnel_Num), which identify the 
tunnel at each end point. The tunnel number is a 16-bit unsigned 
integer unique within the context of the Node_ID. A full Tunnel ID 
is represented by the concatenation of these two end-point-specific 
identifiers. Using the A1/Z9 convention, the format of a Tunnel_ID 
is: 


Al-{Node_ID::Tunnel_Num}: :29-{Node_ID: : Tunnel_Num} 


Winter, et al. Standards Track [Page 7] 


RFC 6923 MPLS-TP ITU-T IDs May 2013 


Where global uniqueness is required, using ITU-T conventions, the 
ICC_Operator_ID is prefixed to the Tunnel_ID. Thus, a globally 
unique Tunnel_ID becomes: 


Al-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: 
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num} 


As per [RFC6370], when an MPLS-TP tunnel is configured, it MUST be 
assigned a unique IF_ID at each end point as defined in Section 4. 


5.2. MPLS-TP LSP Identifiers 


The following subsections define identifiers for MPLS-TP co-routed 
bidirectional and associated bidirectional LSPs. Since MPLS-TP 
Sub-Path Maintenance Entities (SPMEs) are also LSPs, they use the 
same form of IDs. 


5.2.1. MPLS-TP Co-Routed Bidirectional LSP Identifiers 
The LSP Identifier (LSP_ID) for a co-routed bidirectional LSP is 
formed by adding a 16-bit unsigned integer LSP number (LSP_Num) to 


the Tunnel ID. Consequently, the format of an MPLS-TP co-routed 
bidirectional LSP_ID is: 


Al-{Node_ID::Tunnel_Num}::29-{Node_ID::Tunnel_Num}::LSP_Num 


[RFC6370] notes that the "uniqueness of identifiers does not depend 
on the A1/Z9 sort ordering". 


A co-routed bidirectional LSP is provisioned or signaled as a single 
entity, and therefore, a single LSP_Num is used for both 


unidirectional LSPs. These can be referenced by the following 
identifiers: 


Al-Node_ID::A1-Tunnel_Num::LSP_Num::Z9-Node_ID and 
Z9-Node_ID::2Z9-Tunnel_Num::LSP_Num::Al-Node_ID, respectively. 


Global uniqueness is accomplished by using globally unique Node_IDs. 
A globally unique LSP_ID consequently becomes: 


Al-{ICC_Operator_ID::Node_ID::Tunnel_Num}:: 
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num}::LSP_Num 
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5.2.2. MPLS-TP Associated Bidirectional LSP Identifiers 


An associated bidirectional LSP needs a separate LSP_Num for both of 
its unidirectional LSPs. The LSP number is again a 16-bit unsigned 
integer that needs to be unique within the scope of the ingress’s 
Tunnel_Num. Consequently, the format of an MPLS-TP associated 
bidirectional LSP_ID is: 


Al-{Node_ID::Tunnel_Num::LSP_Num}:: 
Z9-{Node_ID::Tunnel_Num: :LSP_Num} 


Each of the unidirectional LSPs of which the associated bidirectional 
LSP is composed may be referenced by one of the following 
identifiers: 


Al-Node_ID::A1-Tunnel_Num: :A1-LSP_Num::2Z9-Node_ID and 
Z9-Node_ID::2Z9-Tunnel_Num: :Z29-LSP_Num::A1l-Node_ID, respectively. 


A globally unique LSP_ID is constructed using the globally unique 
Node_IDs as defined before. Consequently, a globally unique LSP_ID 
is formulated as: 


Al-{ICC_Operator_ID::Node_ID::Tunnel_Num::LSP_Num}:: 
Z9-{ICC_Operator_ID::Node_ID::Tunnel_Num: :LSP_Num} 


6. Pseudowire Path Identifiers 


The PW Path Identifier (PW_Path_ID) is structured in a similar manner 
as the PW_Path_ID described in Section 6 of [RFC6370]. Instead of 
the Global_ID used in [RFC6370], this document uses the 
ICC_Operator_ID to make the PW_Path_ID globally unique. In this 
document, the Attachment Individual Identifier (AII) is composed of 
three fields. These are the ICC_Operator_ID, the Node_ID, and the 
AC_ID. The AC_ID is as defined in [RFC5003]. The complete globally 
unique PW_Path_ID is formulated as: 


Al-{ICC_Operator_ID::Node_ID::AC_ID}:: 
Z9-{ICC_Operator_ID::Node_ID::AC_ID} 


7. Maintenance Identifiers 
The following subsections define the identifiers for the various 
maintenance-related groups and entities as defined in [RFC6371]. In 


contrast to the IDs defined in [RFC6370], this document does not 
define separate maintenance identifiers for Sections, PWs, and LSPs. 
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7.1. MEG Identifiers 


MEG_IDs for MPLS-TP Sections, LSPs, and PWs following ITU-T 
conventions are based on the globally unique ICC_Operator_ID. In 
this case, the MEG_ID is a string of up to 15 characters and consists 
of three subfields: the Country Code (as described in Section 3) and 
the ICC (as described in Section 3) -- which together form the 
ICC_Operator_ID -- followed by a Unique MEG ID Code (UMC) as defined 
in [Y.1731_corl]. 


The resulting MEG_ID is: 
CC::ICC: :UMC 


To avoid the potential for the concatenation of a short (i.e., less 
than 6 characters) ICC with a UMC not being unique, the UMC MUST 
start with the "/" character, which is not allowed in the ICC itself. 
This way, the MEG_ID can also be easily decomposed into its 
individual components by a receiver. 


The UMC MUST be unique within the organization identified by the 
combination of CC and ICC. 


The ICC_Operator_ID-based MEG_ID may be applied equally to a single 
MPLS-TP Section, LSP, or Pseudowire. 


7.2. MEP Identifiers 


TCC_Operator_ID-based MEP_IDs for MPLS-TP Sections, LSPs, and 
Pseudowires are formed by appending a 16-bit index to the MEG _ID 
defined in Section 7.1. Within the context of a particular MEG, we 
call the identifier associated with a MEP the MEP Index (MEP_Index). 
The MEP_Index is administratively assigned. It is encoded as a 
16-bit unsigned integer and MUST be unique within the MEG. An 
ICC_Operator_ID-based MEP_ID is structured as: 


MEG_ID: :MEP_Index 


An ICC_Operator_ID-based MEP ID is globally unique by construction 
given the ICC_Operator_ID-based MEG_ID’s global uniqueness. 


7.3. MIP Identifiers 
ICC_Operator_ID-based MIP_IDs for MPLS-TP Sections, LSPs, and 


Pseudowires are formed by a global IF_ID that is obtained by 
prefixing the identifier of the interface on which the MIP resides 
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with the ICC_Operator_ID as described in Section 3.1. This allows 
MIPs to be independently identified in nodes where a per-interface 
MIP model is used. 


If only a per-node MIP model is used, one MIP is configured. In this 
case, the MIP_ID is formed by using the Node_ID and an IF_Num of 0. 


8. Security Considerations 


This document extends an existing naming scheme and does not 
introduce new security concerns. However, as mentioned in the 
Security Considerations section of [RFC6370], protocol specifications 
that describe the use of this naming scheme may introduce security 
risks and concerns about authentication of participants. For this 
reason, these protocol specifications need to describe security and 
authentication concerns that may be raised by the particular 
mechanisms defined and how those concerns may be addressed. 
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